1. Field of the Invention
The present invention relates to the field of graphical programming, and more particularly to a system and method for static memory allocation (SMA) in a graphical programming system.
2. Description of the Related Art
Traditionally, high level text-based programming languages have been used by programmers in writing application programs. Many different high level text-based programming languages exist, including BASIC, C, C++, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level text-based languages are translated to the machine language level by translators known as compilers or interpreters. The high level text-based programming languages in this level, as well as the assembly language level, are referred to herein as text-based programming environments.
Increasingly, computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. The task of programming a computer system to model or implement a process often is further complicated by the fact that a sequence of mathematical formulas, steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptualize a problem or process and then to program a computer to implement a solution to the problem or process. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his solution, the efficiency with which the computer system can be utilized often is reduced.
To overcome the above shortcomings, various graphical programming environments now exist which allow a user to construct a graphical program or graphical diagram, also referred to as a block diagram. U.S. Pat. Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; among others, to Kodosky et al disclose a graphical programming environment which enables a user to easily and intuitively create a graphical program. Graphical programming environments such as that disclosed in Kodosky et al can be considered a higher and more intuitive way in which to interact with a computer. A graphically based programming environment can be represented at a level above text-based high level programming languages such as C, Basic, Java, etc.
A user may assemble a graphical program by selecting various icons or nodes which represent desired functionality, and then connecting the nodes together to create the program. The nodes or icons may be connected by lines representing data flow between the nodes, control flow, or execution flow. Thus the block diagram may include a plurality of interconnected icons such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables and/or producing one or more output variables. In response to the user constructing a diagram or graphical program using the block diagram editor, data structures and/or program instructions may be automatically constructed which characterize an execution procedure that corresponds to the displayed procedure. The graphical program may be compiled or interpreted by a computer.
A graphical program may have a graphical user interface. For example, in creating a graphical program, a user may create a front panel or user interface panel. The front panel may include various graphical user interface elements or front panel objects, such as user interface controls and/or indicators, that represent or display the respective input and output that will be used by the graphical program, and may include other icons which represent devices being controlled.
Thus, graphical programming has become a powerful tool available to programmers. Graphical programming environments such as the National Instruments LabVIEW product have become very popular. Tools such as LabVIEW have greatly increased the productivity of programmers, and increasing numbers of programmers are using graphical programming environments to develop their software applications. In particular, graphical programming tools are being used for test and measurement, data acquisition, process control, man machine interface (MMI), supervisory control and data acquisition (SCADA) applications, modeling, simulation, image processing/machine vision applications, motion control, and embedded applications, among others.
Many applications require, or may benefit from, reliable performance with respect to execution timing. In other words, it may be important or beneficial for functions or events to be performed by a program with strict timing constraints. For example, an industrial measurement and control program may be required to take measurements at precise intervals of one millisecond, and send control signals, e.g., to an actuator, every five milliseconds. Systems with such timing requirements may be referred to as “real time” systems, and may be based on embedded processor technologies, workstations or personal computers, programmable hardware elements, such as field programmable gate arrays (FPGAs), or any other computational hardware.
However, programs that rely on dynamic memory allocation and deallocation may have difficulty meeting such timing requirements due to variability in performance caused by memory management overhead. This variability in performance may be referred to as “jitter”. For example, depending on factors such as memory management algorithms, the state of the heap, e.g., level of fragmentation, and so forth, the time spent performing an allocation or deallocation may vary substantially, and may thus impact the timing of other functions performed by the program.
One approach for mitigating or eliminating this problem is to use static memory allocation, where all memory required by the application program is allocated at runtime prior to executing the program instructions, as opposed to dynamic memory allocation and deallocation, performed while the program is executing.
However, some prior art graphical programming systems do not support exclusive static memory allocation (i.e., no dynamic memory management), and those that do have shortcomings that may substantially limit the benefits of such an approach. For example, prior art approaches that support exclusive static memory allocation typically result in programs with very large memory footprints, due to the fact that memory allocated statically for data structures is reserved for the execution life of the program, even if some of the data structures are only used or needed for some of the time. For example, if a five megabyte array is used during an initialization procedure of the program, but not used thereafter, that five megabytes is still reserved for the duration of the program execution, and so remains unused for most of the time. Such inefficiencies may limit the applicability of this approach in many application domains, such as, for example, in embedded systems that have extremely limited memory resources.